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Method and Apparatus to Achieve Minimum Cost On-line Access 

R A f?K flR OI JND OF THE INVENTION 

1. Field of the Invention 

This invention is in the field of telecommunications, as it relates to the 
use of network address and user criteria information for network transactions. 

2. nmss-References to Related Applications 

The present application is an continuation in part of U.S. patent 
application entided, "A METHOD AND APPARATUS FOR USING NETWORK 

address Information to improve the performance of network 
TRANSACTIONS," having application no. , and filed on June 3, 1996. 

The present application is also related to the following co-pending U.S. 
patent applications: 

U.S. Patent application entided, "Web Browser Allowing Navigation 
Between Hypertext Objects Using Remote Control," having application no. 
, and filed on ; and 

U.S. Patent application entided, "Method and Apparatus for Providing 
Proxying and Transcoding of Documents in a Network," having application no. 
, and filed on ; and 

U.S. Patent application entided, "Method and Apparatus For Managing 
Communications Between a Client and a Server in a Network," having 

application no. , and filed on ; 

which are assigned to the assignee of the present invention. 

3. Description of Related Art 

The internet is a modern communication system that allows computer 
operators a means to network with other operators as well as a variety of 
databases. These databases provide a great deal of useful information, the 
dissemination of which is gready enhanced by use of the internet. Participation 
in this modem network entails establishing an account with an internet access 
provider or on-line service provider such as Netcom, UUNet, AT&T Worldnet, 
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or America On-line. The user is given an account and a phone number (and 
perhaps alternate phone numbers in case the first number is busy or if he moves 
to a different location) to type into his client software, and then the client 
software dials the entered phone number to connect to the access provider. 

Similar to long distance telephone service providers, internet access 
providers are faced with routing large numbers of customers attempting to access 
the system at different times. As a result, each provider incurs peak periods that 
are characteristic of the providers particular customer base and corresponding off 
peaks. For example, if a provider caters to business customers, it is busy during 
normal business hours. On the other hand, if a provider caters to consumers, it is 
busy in off business hours such as evenings and holidays. During these off hours 
and holidays, providers that cater to consumers may be burdened by requests that 
overlook the system. On the other hand, during business hours, providers that 
cater to consumers go underutilized. Business providers, on the other hand, 
would experience peak hours during normal business hours and go underutilized 
during non-business hours. 

The cost of this inconsistent use of a provider's system is spread out over 
all users regardless of whether they use the system during peak hours or off peak 
hours. Furthermore, access can be limited during peak hours when the system is 
overloaded, leaving users with a busy signal when trying to access the 
overloaded system. 

As a result, access providers must charge all customers accordingly in 
order to cover for periods where the modem pools are underutilized. Also, 
access providers that offer nationwide service at a consistent rate throughout the 
country may incur far more costs from users dialing in from congested or 
isolated areas than providers would incur from users in less congested and not so 
isolated areas. They therefore fail to get optimal use of their modem pools in 
these underutilized areas. Still further, if an internet access provider has no peak 
operating period in an isolated area, a user may be forced to incur a higher cost 
by acquiring long distance service in order to reach an internet access provider, 
adding long distance charges to the connect time charges. 

Thus, it would be useful to provide a service or device that could 
efficiently route customers of internet access providers among a variety of 
internet access providers in order to reduce the cost of internet access as well as 
to make optimal use of the systems provided by internet access providers. As 
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will be seen, the present invention accomplishes this in a useful and elegant 
manner. 

Conventional computer network protocols are designed to operate within 
a given network topology. These protocols are flexible enough to handle many 
different arrangements of nodes and robust enough to handle changes in the 
topology as computers are added or removed from the network. Because of the 
need to maintain flexibility and mobility, conventional networks do not rely on 
information that is specific to a particular geographic location. These network 
protocols usually consider geographic independence to be an advantage. 

In many areas of the United States, it is possible to determine a calling 
telephone number from the telephone network. Telephone network services such 
as Caller ID and Automatic Number Identification (ANI) can provide a caller's 
telephone number to a suitably equipped telephone answering device, and then 
the telephone number can be transferred to a server coupled to the answering 
device. 

In many calling areas, however, Caller ID and Automatic Number 
Identification are not available either for technical or legislative reasons. In such 
areas it may be possible to verify a user's area code, and possibly the calling area 
(e.g. city), but in some cases no identification at all is possible. Without a direct 
method to identify or verify a user's telephone number, indirect methods can be 
used. 

In various ways, therefore, conventional means are available for 
obtaining information pertaining to a particular network node or network user. 
Although this information is available, conventional network protocols do not 
provide the functionality to obtain this information or to use the information to 
optimize the operation of the network. 

Thus, a better means and method is needed for optimizing network 
transactions. 

SUMMARY QF THE INVENTION 

A database central routing device is provided for routing incoming access 
requests for internet access among a variety of on-line service providers. The 
device generally includes a central server having a list of algorithms pertaining to 
access phone numbers of internet access providers to be chosen from. The 
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central routing device further includes an automatic phone number identifier to 
identify incoming calls in order to identify the user as a customer. An algorithm 
generator is also included in order to download algorithms pertaining to 
particular phone numbers in order to give the user access to a variety of internet 
access providers. The central routing device allows the user to select from a 
number of internet access providers depending on the availability of the 
providers. Factors such as time of day, consistent peak and off peak hours of any 
particular provider, the time of access, the type of user such as consumer or 
business user, and other factors in order to make efficient use of a variety of 
internet access providers. 

These and other advantages of the present invention are fully described in 
the following detailed description of the preferred embodiment. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The features and advantages of the present invention will be apparent 
from the accompanying drawings and from the detailed description of the 
preferred embodiment of die present invention as set forth below. 

Figure 1 illustrates the present invention as implemented on a module for 
use in a television set. 

Figure 2 illustrates the present invention as implemented with an 
integrated cable modem and decoder. 

Figure 3 illustrates the present invention as integrated in a television set 

Figure 4 illustrates the present invention as implemented with a cable 
modem and video input 

Figure 5 illustrates the present invention as implemented with an ISDN 
modem. 

Figure 6 illustrates the network configuration of the present invention. 

Figure 7 illustrates the network configuration of the present invention 
with point of presence (POP) nodes. 

Figure 8 illustrates the internal structure of the WebTV client of the 
present invention. 

Figure 9 illustrates the internal structure of the private server of the 
present invention. 

Figure 10 illustrates the internal structure of the WebTV server of the 
present invention. 
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Figures 11*16 arc flowcharts illustrating the processing logic flow of the 
present invention; 

Figure 17 illustrates a network configuration of the present invention; 

and 

Figure 18 is a flowchart illustrating the function of the method to achieve 
minimu m cost on-line access. 

DETAILED DESCRIPTION O F THE PREFERRED EMBODIMENT 

The present invention is an apparatus and method for using network 
address information to improve the performance of network transactions. In the 
following detailed description, numerous specific details are set forth in order to 
provide a thorough understanding of the present invention. However, it will be 
apparent to one of ordinary skill in the art that these specific details need not be 
used to practice the present invention. In other instances, well known structures, 
interfaces, and processes have not been shown in detail in order not to 
unnecessarily obscure the present invention. 

WebTV™ 

The preferred embodiment of the present invention is a low-cost network 
TM 

interface device (WebTV ) that uses a standard television set as a display 
device and standard telephone lines and/or other residential communication 
networks as a network transport medium. The network interface device can be 
implemented as a system in various forms. Figure 1 illustrates the network 
device as a module inserted into a jack provided on a standard television. Figure 
2 illustrates the network interface device as a device with an integrated cable 
modem and decoder built in. Figure 3 illustrates the network interface device as 
an integrated unit built into a television set Figure 4 illustrates the network 
interface device as a device with a built in video interface and cable modem. 
Figure 5 illustrates the network interface device with a built in ISDN (Integrated 
Services Digital Network) modem* In each case, a standard telephone connection 
is provided for the network interface device of the present invention to enable 
communication over the conventional telephone network. In configurations with 
cable modem capability, communication over a cable network is possible in 
addition to communication over the telephone network. The cable network is 
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typically much faster (i.e. provides a much greater bandwidth) than the standard 
telephone network; however, cable modems arc typically more expensive than 
standard POTS (as it is known in the art, "Plain Old Telephone Service") 
telephone modems. In an ISDN configuration, the network interface device has 
both an ISDN modem and a standard POTS modem. Again, the ISDN network is 
typically faster than the POTS telephone network; however, ISDN is currently 
more expensive. 

In the preferred embodiment and in the description that follows, the 
present invention is described in the context of several different types of 
networks or portions of a network. Specifically, the following definitions clarify 
the different network types in which the preferred embodiment operates. These 
different network types include: the conventional POTS telephone network, the 
Internet network, World Wide Web (WWW) network, and the WebTV network. 
The POTS telephone network is a switched-circuit network that connects a client 
to a point of presence (POP) node or directly to a private server. The POP node 
and the private server connect the client to the Internet network, which is a 
packet-switched network using a transmission control protocol/Internet protocol 
(TCP/IP). The World Wide Web (WWW) network uses a hypertext transfer 
protocol (HTTP) and is implemented within the Internet network and supported 
by hypertext mark-up language (HTML) servers. The WebTV network uses an 
HTTP-based set of protocols implemented within the WWW network and 
supported by one or more HTML servers. 

The WebTV network connects each client having a WebTV network 
interface device to other WebTV clients and to WebTV services. WebTV clients 
can also browse information on a wide-area network reached through one of the 
network connections, such as the Internet or World Wide Web (WWW), using 
the network interface device and the browser software provided therein. 
Although the WebTV browser is capable of browsing the World Wide Web 
direcdy, the WebTV network improves services beyond basic Internet access in 
several ways. WebTV network services, including user registration and 
electronic mail (email) are provided on the WebTV network. The WebTV 
network also improves user services by accelerating browsing to far away WWW 
sites and by eliminating delays. In addition, the WebTV network provides 
content tailored to the WebTV client's geographic area (geographic tailoring). In 
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this manner, client access to localized services is improved. The WebTV network 
interface device can also efficiently tailor a response to a client or use an 
appropriate network medium that relates to a particular client request. For 
example, the higher cost ISDN or cable network media can be used when high 
data rates are required, while the less expensive POTS telephone network can be 
used for less critical or lower data rate transactions. The WebTV network can 
also offload storage from the WebTV network interface device, thereby reducing 
its cost. 

Referring to Figure 6, the basic construct of the WebTV network of the 
present invention is illustrated. A plurality of WebTV clients 610, each being a 
network interface device such as the WebTV network interface device described 
above, are coupled to a WebTV server 620 via a conventional network 
infrastructure 612, such as the Internet and WWW. The WebTV server 620 is a 
standard networked computer system (e.g. a Sun Microsystems SparcStation) 
upon which software implementing the network functionality of the present 
invention is executed. This functionality is described below. 

Referring to Figure 7, an alternative embodiment of the basic construct of 
the WebTV network of the present invention is illustrated. A plurality of WebTV 
clients 610, each being a network interface device such as the WebTV network 
interface device described above, are alternatively coupled to a plurality of point 
of presence (POP) nodes 710. The point of presence nodes 7 10 provide a means 
by which clients 610 can access the network 612 through a local node rather than 
incurring higher cost direct connections to network 612. In a telephone network, 
for example, it is less expensive for a client 610 to establish a telephone 
connection with a local point of presence node 710 (i.e. modem in the case of a 
telephone network) in the local calling area of the client 610 rather than make a 
long distance call to a node of network 612. In the configuration shown in Figure 
7, cost benefits for the client can be realized. The present invention, however, is 
not constrained to this configuration. Rather, the present invention can be 
implemented in either of the network configurations illustrated in Figure 6, 
Figure 7, or other equivalent network configurations. 
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Use of Automatic Number Identification (AND for security verification »nH 

authentication purposes. 

ANI can be a effective tool for verifying the location from which a 
network access is being made. For example, a WebTV client network interface 
device 610 may access the WebTV network server 620 to request a particular 
type of service. In some circumstances, it is necessary or desirable to verify a 
client's identity before performing the requested service. Telephone network 
services such as Caller ID and Automatic Number Identification (ANI) can be 
used to provide a requesting client's telephone number to the WebTV server 620. 
This can be performed transparently to the client user. The WebTV server 620 
may use the requesting client's telephone number to authorize the completion of 
a requested service by comparing the requesting client's telephone number to a 
list of authorized telephone numbers maintained in the server 620. If the 
requesting client's telephone number is on the server list, the requested service is 
completed for the client If the requesting client's telephone number is not on the 
server list for the requested service, the client is notified that the requested 
service cannot be performed. Since ANI and Caller ID cannot be faked by a 
surreptitious user, this feature of the present invention allows the WebTV 
network to provide a significant level of security for network transactions. This 
authentication feature is described in more detail in the following sections. 

There are a very few areas of the U.S. where ANI is not available. In 
such areas, the private server of the present invention will detect the lack of ANI 
and direct the client software to prompt the user for entry of a telephone number. 
Although the present invention cannot verify the accuracy of the user-entered 
telephone number, the present invention can nevertheless verify that the user- 
entered telephone number is not a telephone number from an area with ANI 
coverage. 

Another test can be performed to verify that the assumed telephone 
number (whether obtained from ANI or user entry) of a client network interface 
device 610 is probably correct That is, the client software in the client network 
interface device 610 can direct the client to dial its own assumed telephone 
number. If the dialed telephone number is not busy (i.e. a ring signal or 
disconnect signal is detected), the assumed client telephone number cannot be 
correct If the dialed telephone number is busy, the assumed client telephone 
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number probably is correct; because, most telephone numbers are not busy the 
vast majority of the time. These tests provide a nominal level of client telephone 
number validation in areas with or without ANI service. 

Even in the very few areas of the U.S. and most of the world where ANI 
service is not available, the process of the present invention for obtaining a 
secure encryption key and for performing secure transactions via a secure 
network to a private server still operates. The only capability lost in these areas 
is the automatic verification of geographic locality provided by the present 
invention and described in more detail below. 

Referring now to Figures 8 through 15, block diagrams and flow charts 
illustrate the authentication feature of the preferred embodiment of the present 
invention. Referring now to Figure 8, the interface between the WebTV client 
610 and the conventional network 612 is illustrated. In the preferred 
embodiment, WebTV client 610 transmits and receives information over a direct 
communication channel 852 through network interface 840- Many conventional 
communication channels such as channel 852 exists in the prior art These 
communication channels include conventional POTS telephone lines through 
modems, integrated services digital network (ISDN) lines, dedicated wire or 
fiber optic lines. 

Alternatively, WebTV client 610 may be coupled to conventional 
network 612 through a point of presence node 810. As described earlier, point of 
presence node 810 provides a means for WebTV client 610 to interface with 
conventional network 612 through a local point of presence node 810. In this 
manner, the communication channel 854 between client 610 and point of 
presence node 810 can be a less expensive channel than the direct connect 
channel 852. In either configuration, WebTV client 610 is enabled to transmit 
and receive information via conventional network 612. 

One characteristic of the conventional network 612 such as the Internet 
is the relatively insecure transmission environment over the conventional 
network. Because of this insecure characteristic of conventional network 612, 
confidential communications, commercial transactions, or other transfers of 
information or transactions requiring a secure environment cannot take place. 
For this reason, the present invention adds additional functionality to 
authenticate a particular WebTV client and establish a secure and confidential 



WO 98/04088 PCT/US97/12423 



-10- 

communication between WebTV client 610 and WebTV server 620. A private 
server 820 is used in the preferred embodiment of the present invention to create 
a secure network environment in a manner to be described in more detail below. 

Referring again to Figure 8, private server 820 is shown coupled to client 
610 via a secure communication line 858. Secure communication line 858 can 
be any of a number of conventional secure communication techniques employed 
in the prior art including direct POTS telephone line connections, dedicated 
transmission lines* or point-to-point data communications media. In the 
preferred embodiment, a secure communication between WebTV client 610 and 
private server 820 is established by use of a pre-assigned (800) telephone number 
that establishes a direct point-to-point communication link between private 
server 820 and client 610. In this manner, a secure communication environment 
between client 610 and private server 820 can be guaranteed. Using the 
techniques of the present invention as described below, WebTV client 610 
initially establishes a secure communication with private server 820 in order to 
subsequently establish a secure communication environment through 
conventional network 612. 

In order to establish a secure communication environment with 
conventional network 612, WebTV client 610 includes a client box identifier 
842. Client box identifier 842 is an electronically readable unique number or 
alphanumeric string which differentiates a particular WebTV client unit 610 
from all others. Conventional techniques are well known for installing a unique 
identification code in an electronic device. 

WebTV client 610 also includes an encryption key storage area 844 and a 
network address storage area 846. Storage areas 844 and 846 are electronically 
readable and modifiable memory locations used for the storage of particular 
items of information used during the authentication process of the present 
invention. Encryption key storage area 844 is used for the storage of an 
encryption key provided by the private server °20 and used by client 610 in its 
communications through conventional network 612. Network address storage 
area 846 is used for the storage of a network address at which WebTV client 610 
is currently located. In the case of a telephone link between client 610 and 
network 612, the client network address represents the telephone number from 
which client 610 is calling. Both encryption key. 844 and network address 846 
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may be stored in a variety of conventional memory means including battery- 
backed CMOS memory, flash memory, dynamic random access memory 
(DRAM), or static random access memory (SRAM). 

Referring now to Figure 9, the internal components of private server 820 
(first server) used for authentication are illustrated. Private server 820 includes 
network address determination logic 910. Network address determination logic 
910 is used by private server 820 to determine a network address from which a 
client 610 is communicating. In the case of a telephone network, network 
address determination logic 910 comprises automatic number identification 
(ANI) logic for determining the telephone number from which client 610 is 
calling. The use of ANI is well known to those of ordinary skill in the art. 
Private server 820 employs this conventional technique in a novel and useful 
way for authenticating a client 610 in a networked computer environment 

Conventional computer systems and networks provide secure 
transactions, typically by use of an encryption key. The need for an encryption 
key is assumed for conventional secure transactions. There are many techniques 
known in the art for utilizing an encryption key to effect secure transactions on 
an open channel (e g. Rivest, Shamir, Adleman (RSA) protocol, Secure Socket 
Layer (SSL) protocol, etc.); however, all of these conventional techniques are 
compromised when there is not a secure channel for transferring the encryption 
key between the client and the server. In the present invention, a secure POTS or 
ISDN network provides the secure channel over which the encryption key can be 
safely and securely transferred between the client and the private POTS or ISDN 
server. Thereafter, an insecure network (Le. the Internet, WWW, or other public 
insecure network) can be used for normal secure data transactions between the 
client the server using the encryption key previously obtained over the secure 
network. This process of using a secure network to obtain an encryption key 
which is later used on an insecure network is not part of the prior art and an 
important part of the authentication process of the present invention* 

Referring again to Figure 9, private server 820 includes encryption key 
generation logic and storage 912. Because the data communication line 858 
between client 610 and private server 820 is a private and secure communication 
line, private server 820 can be used by client 610 to generate and provide a 
unique encryption key for client 610. The encryption key for a particular 
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WebTV client 610 is generated by logic 912 and stored in association with the 
network address of the client 610 for which the encryption key was generated. 
Point of presence node locality determination logic 914 in private server 820 is 
used to determine the closest point of presence node to the client 610 requesting 
such information from private server 820. Using client network address 
information determined by logic 910, point of presence node locality 
determination logic 914 can access an internal list of point of presence nodes to 
determine which node on the list is closest to the corresponding client network 
address. A typical transaction between client 610 and private server 820 is 
described below in more detail in connection with the flow charts of Figures 1 1 
through IS. 

Referring now to Figure 10, internal components of WebTV server 620 
(second server) are shown. WebTV server 620 is coupled to conventional 
network 612 via data communication line 1020. Data communication line 1020 
comprises any of a variety of conventional network access means including 
digital telephone links, ISDN lines, cable links, wireless transmission, or any of a 
variety of other conventional means. WebTV server 620 provides a variety of 
services customized for a WebTV client 610. It is critical, however that the 
transaction between client 610 and WebTV server 620 be a secure data 
communication link. This is not always possible on an insecure network like 
network 612. For this reason, WebTV server 620 provides client authentication 
data 1010. Client authentication data 1010 represents information indicating a 
client network address and a client box identifier associated with each particular 
client In addition, WebTV server 620 retains an encryption key associated with 
each particular client in client encryption key storage area 1013. These items of 
information are maintained for each client accessing WebTV server 620. The 
manner in which this information is used to authenticate a client is described in 
more detail in connection with the flow charts of Figures 1 1 through 15. 

WebTV server 620 also maintains network geographical data 1012. It is 
convenient in many circumstances to determine the geographical locality of a 
particular WebTV client 610. Using client geographical locality information, 
services requested by a particular client can be better configured and optimized 
based on the client locality information. Network geographical data 1012 
represents information associating particular client network addresses with a 
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corresponding geographical locality. The use of this information by WebTV 
server 620 is described in more detail in connection with the flow charts of 
Figures 11 through 15. 

Referring now to Figure 1 1, a flow chart illustrates the processing 
performed by a WebTV client 610. The logic illustrated in Figure 1 1 is used by 
a client 610 to establish a secure data communication link with a WebTV server 
620 over a conventional insecure data network. In a first processing step 1 1 10, 
client 610 performs a power-up initialization. Next, client 610 connects to 
private server 820 over a secure network line 858. Once client 610 is connected 
with private server 820, client 610 requests the private server 820 to determine 
the client network address of client 610. Because it is not always possible for 
client 610 to determine its own network address, this information must be 
requested from private server 820. If access by client 610 to conventional 
network 612 is performed using a standard POTS telephone network, private 
server 820 can use conventional automatic number identification (ANI) 
functionality to obtain the telephone number from which client 610 is calling. In 
the POTS telephone network situation, this client telephone number represents 
the client network address from which the client 610 is accessing the network. 
Once the private server 820 obtains the client network address, this client 
network address is stored on private server 820 and/or provided back to the 
requesting client 610. In addition, the private server 820 generates an encryption 
key for the client 610. This encryption key is specific to that particular client and 
is used for encrypting subsequent data communications between client 610 and 
WebTV server 620 (processing block 1112). 

Referring now to Figure 12, the private server 820 processing logic is 
illustrated. In processing block 1210, the private server 820 receives a request 
from a client 610 for a determination of the client's network address and the 
generation of an encryption key for the client. The private server 820 uses 
conventional techniques to obtain the client network address in processing block 
1212. In the case of a POTS telephone network connection between private 
server 820 and client 610, private server 820 uses conventional automatic 
number identification (ANI) techniques to obtain the client telephone number 
from where the telephone call to the private server 820 originated. In the 
preferred embodiment, private server 820 provides a known (800) telephone 
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number which a client 610 may use to access private server 820. Once this 
connection to private server 820 is made, the network address determination 
logic 910 of private server 820 uses standard telephone ANI functionality to 
determine the telephone number or network address of the client 610 which 
originated the telephone call (processing block 1212). 

In processing block 1214, private server 820 checks a storage location 
within encryption key storage 912 to determine if an encryption key for the 
requesting client has already been determined. If this is not the case, a new and 
unique encryption key for this particular client is generated by encryption key 
generation logic 912 using conventional techniques. This newly generated 
encryption key for the client is then stored in encryption key storage 912. 

In processing block 1216, the client network address is used by the 
private server 820 to determine which point of presence node is local to the 
clients network address. The point of presence node locality determination logic 
914 of private server 820 includes information indicating which point of 
presence nodes are local to a particular block of client network addresses. The 
logic within point of presence node locality determination logic 914 compares 
the particular client network address with a block of client network addresses to 
determine the point of presence node that is local for the corresponding block of 
client network addresses. In the case of a telephone network, the client network 
address corresponds to a client telephone number which includes an area code. 
In some cases a point of presence node having the same area code as the client 
network address represents a point of presence node which is local to the client 
network address. In other circumstances, it is necessary to obtain other 
information which defines whether or not a point of presence node telephone 
number is local to a particular client network address. In either case, 
conventional techniques are known for making the association between point of 
presence node telephone numbers and client telephone numbers. Using logic 
914, private server 820 finds the telephone number of a point of presence node or 
modem which is in the local calling area of the client represented by the cli nt 
network address (processing block 1216). 

In processing block 1218, private server 820 returns a message to the 
requesting client indicating the client network address, the client encryption key, 
and the network address of a local point of presence node. This information, 
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generated or obtained by private server 820 is provided to client 610 in 
processing block 1218. Private saver processing then terminates through the 
exit block illustrated in Figure 12* 

Referring again to Figure 1 1, the client network address and the client 
encryption key is obtained by the client from the private server 820 in processing 
block 1 1 12 as described above* The client network address is stored in network 
address storage area 846 illustrated in Figure 8. The client encryption key 
obtained from private server 820 is stored in encryption key storage area 844 
illustrated in Figure 8. Both the client network address and the client encryption 
key are stored in secure client storage areas 846 and 844, respectively 
(processing block 1 1 14). 

The network address of a local point of presence node is obtained by 
client 610 from private server 820 in processing block 1116. The network 
address of the local point of presence node is determined by private server 820 as 
described above in connection with figure 12. 

In processing block 1118, client 610 disconnects from private server 820. 
Once client 610 obtains the client network address, the client encryption key, and 
the network address of a local point of presence node from the private server, 
communication with private server 820 is no longer necessary. Therefore, client 
610 can disconnect from the private server 820. This aspect of the present 
invention represents an advantage in that the client 610 does not need to maintain 
a prolonged secure connection with private server 820. Client 610 establishes a 
connection with the local point of presence node identified by private server 820. 
In the case of a POTS telephone network, client 610 dials the telephone number 
of the local point of presence node and initializes a data connection with the 
modem of the local point of presence node. 

In processing block 1 120, client 610 opens a connection with the WebTV 
server 620 through the point of presence node using the client encryption key to 
establish a secure connection with the WebTV server 620 over an insecure 
network line 1020. Figures 13 and 14 describe the WebTV server 620 
processing logic in more detail from the perspective of the server 620. On the 
client side, client 610 requests a connection with WebTV server 620 in block 
1 120 then exits through the exit block illustrated in Figure 1 1 . 
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Referring now to Figure 13, the WebTV server 620 processing logic is 
illustrated In block 1310, server 620 receives a request from a client 610 for an 
open connection. Because a transaction between a client 610 and WebTV server 
620 must be a secure transaction, it is necessary for WebTV server 620 to 
authenticate the client from which a connection request is received. The client 
box identifier and the client network address received from the client can be used 
by WebTV server 620 to authenticate the client 610. However, it is necessary 
for the WebTV server 620 to obtain the client encryption key in order to decrypt 
the encrypted messages received from client 610. This client encryption key 
cannot be transferred to WebTV server 620 over an insecure data communication 
line. WebTV server 620 must obtain the client encryption key from a secure 
source. In the preferred embodiment, private server 820 can be used by WebTV 
server 620 as a source for obtaining the client encryption key. In the same 
manner that client 610 established a connection with private server 820, WebTV 
server 620 can establish a private and secure data communication line with 
private server 820. In processing block 1311, WebTV server 620 opens a secure 
connection with private server 820 over a secure network line and obtains the 
client encryption key using the client box identifier and the client network 
address received from the client in the open connection request 

Referring now to Figure 15, the private server 820 processing logic for 
handling a request from WebTV server 620 is illustrated in flow chart form. In 
processing block 1510, private server 820 receives a request from WebTV server 
620 for the encryption key associated with a particular client identified by a 
client box number and a client network address. Private server 820 first verifies 
that the requester is in fact the WebTV server 620 using a predefined passcode 
associated with the WebTV server 620. The encryption key generation logic 912 
of private server 820 then uses the client box number and client network address 
provided by the WebTV server 620 to obtain the encryption key for the 
identified client (processing block 1514). If the identified client had previously 
established a connection with private server 820, the encryption key associated 
with that client will be stored in encryption key generation storag area 912. 
This client encryption key is retrieved from storage area 912 by private server 
820 and transferred to WebTV server 620 in a secure message in processing 
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block 1518. Private server processing then terminates at the exit block illustrated 
in Figure 15. 

Referring again to Figure 13 at processing block 1311* WebTV server 
620 has obtained the client encryption key from private server 820. WebTV 
server 620 can now disconnect from the private server 820. WebTV server 620 
updates its own encryption key storage area 1013 with the client encryption key 
retrieved from private server 820. 

In processing block 1312, the WebTV server 620 authenticates the 
requesting client using the client box identifier and the client network address. 
The client box identifier and the client network address are compared with client 
authentication data maintained in WebTV server 620 in client authentication data 
storage area 1010. Using the client box identifier and the client network address, 
it can be determined that a particular WebTV client box is operating at a 
particular network address. If further authentication is required in an alternative 
system, a password or account code may also be requested from the client 610 
and/or a particular user. All this information can be stored and managed within 
client authentication data storage area 1010 on WebTV server 620. If the client 
box identifier and client network address are found and authenticated within 
client authentication data 1010, a connection is opened between client 610 and 
WebTV server 620 in processing block 1316. WebTV server 620 processing for 
the authenticated client then continues at the bubble labeled A illustrated in 
Figure 14. If, however, the client is not authenticated, an error message is 
returned to the requesting client indicating an authentication failure in processing 
block 1318. Processing for WebTV server 620 then terminates at the exit block 
illustrated in Figure 13. 

An ANI-verification connection from a client to a private server typically 
costs more (approximately $0.02 for 20 seconds) than the local call to a point of 
presence node. Thus, it is not cost effective to perform ANI verifications too 
often. However, it is worth performing ANI verification upon: 1) initial 
activation of a client box (i.e., network interface device), 2) periodically to make 
sure the client box has not moved to a different telephone number, or 3) 
whenever suspicious activity (e.g. multiple failed password attempts) occurs on a 
client box. It will be apparent to one of ordinary skill in the art that the ANI 
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verification processes taught herein can be employed in a number of different 
circumstances. 

In an alternative embodiment of the present invention, the WebTV server 
620 and private server 820 can be one in the same computer system. In this 
embodiment, the transaction between WebTV server 620 and private server 820 
for exchanging a client encryption key will not be necessary as the client 
encryption key will already be resident within the same system* In this situation, 
the WebTV server 620 will merely retrieve the client encryption key from an 
encryption key storage area 912 of the combined server system. 

Referring now to Figure 14, WebTV server 620 processing continues for 
an authenticated client at the bubble labeled A. In this circumstance, a data 
communication connection between the client 610 and WebTV server 620 has 
been opened. Because both client 610 and WebTV server 620 have a common 
encryption key as obtained in the processing steps described above, the 
communication between client 610 and server 620 can be encrypted thereby 
providing a secure communication line over an otherwise insecure network 
connection. Therefore, subsequent service requests from client 610 and 
corresponding responses from WebTV server 620 can be encrypted and secure 
data communication can be ensured. 

In processing block 1410 illustrated in Figure 14, an encrypted service 
request is received by WebTV server 620 from client 610. A client network 
address is typically provided as part of the client service request Although the 
client network address typically represents a logical network location of the 
client, in some networks, the client network address can also be associated with 
the geographical location of the client. For example, in a POTS telephone 
network, the client network address is represented as the telephone number of a 
client Using conventional techniques, a telephone number can be associated 
with a geographical location. The area code is a typical component of a client 
telephone number. The area code is associated with a well defined geographical 
region as established by the conventional tel phone companies that manage the 
telephone network. In addition, the three digit prefix of a seven digit telephone 
number further identifies a particular geographical sub-region within the region 
identified by the area code. The remaining four digits of a seven digit telephone 
number further define a particular location within the said-defined sub-region. 
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Using this conventional telephone number information, a set of network 
geographical data can be generated which associates telephone numbers with 
particular geographical locations. This information is stored in WebTV server 
620 in network geographical data 1012. In network environments other than a 
telephone network, other associations between client network addresses and 
corresponding geographical locations can be defined and stored in network 
geographical data 1012. 

Client 610 benefits in a number of ways by having WebTV server 620 
able to ascertain the geographical locality from which client 610 is 
communicating with WebTV server 620. For example, various client service 
requests can be optimized based on the geographical locality from which the 
service request is originated. In the case of a business transaction for example, a 
client may request the delivery of goods through WebTV server 620. By 
knowing the geographical locality from which the client originated the delivery 
request, WebTV server 620 can select a delivery station geographically closest to 
the requesting client In other circumstances, the particular services provided by 
WebTV server 620 may differ depending upon the geographical location of a 
client. For example, the cHent may request the delivery of a high data rate 
information stream to the client site. This high data rate information stream may 
represent a video stream, an audio stream, or other content intensive information 
stream. Depending upon the information stream infrastructure surrounding the 
client locality, WebTV server 620 may choose an optimal information stream 
delivery mechanism. For example, the geographical location at which a client is 
originating a request may have integrated services digital network (ISDN) 
service available at that location. If this is the case, WebTV server 620 can 
automatically configure delivery of information to a particular client over the 
ISDN network. On the other hand if cable modem service is available at the 
client locality, WebTV server 620 may alternatively deliver high data rate 
information to client 610 using a cable modem service. Either of these options 
may be optimally selected by WebTV server 620 using the geographical locality 
information corresponding to a particular client as maintained in network 
geographical data 1012 and associated with a particular client network address. 

In the case of a telephone network, the server 620 uses the requesting 
client's telephone number to determine a geographical location of the client 
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without the client having to specify its address, telephone number or other type 
of locality information. The telephone number is mapped to a geographical 
location using well known techniques, such as an area code map database* Using 
the requesting client's telephone number, the service provider or WebTV server 
620 can select an appropriate supplier or warehouse closest to the client's 
location. Without knowledge of the client's location, an inefficient delivery 
scenario might result. For example, a client could order goods from a supplier 
who delivers the goods from a distant warehouse even though a similar 
warehouse was located close to the client's location. 

In other situations, a service provider can customize the services provided 
based on the requesting client's telephone number For example, a specific menu 
of items associated with particular geographic locations can be offered for 
particular clients based on the ANI-derived requesting client's telephone number. 
In another example, service offerings, prices of offerings, or times of offerings 
can be varied based on the ANI-derived requesting client's telephone number. 

Referring again to Figure 14, if the client service request can be 
optimized for a particular geographical location associated with the client, the 
client network address is obtained in block 1414. Using the client network 
address, WebTV server 620 accesses the network geographical data 1012 to 
determine the corresponding client geographical locality (processing block 
1416). Using the client geographical locality thus obtained, the client service 
request can be optimized in processing block 1418. WebTV server 620 
processing then terminates at the exit block illustrated in Figure 14. If in 
decision block 1412, the service request cannot be optimized based on 
geographical locality, this portion of WebTV server processing then terminates 
at the exit block illustrated in Figure 14. 

In another embodiment of the ANI private server of the present invention, 
the private server 820 can be used to effect secure portions of an otherwise 
insecure transaction. For example, a user might browse a catalog, 
product/service listing, or other commercial information on the WWW network 
through an insecure connection; but, when the user is about to make a purchase 
and transmit a credit card number, personal information, or other confidential or 
proprietary information, the client 610 disconnects from the WWW (i.e., the 
insecure network) and dials the private server 820 through a secure direct 
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telephone call on the secure network in the manner described above in 
connection with Figure 11. The private server 820 makes sure the ANI of the 
client 610 corresponds to the expected telephone number of the client box. If the 
ANI of the client 610 does not correspond to the expected telephone number of 
the client box (e.g. if a hacker attempts to forge a transaction from a pay 
telephone), the private server 820 rejects the transaction. Otherwise, if die client 
ANI does correspond to the expected telephone number of the client box, the 
client is validated. The validated client conducts a secure portion of its 
transaction on the secure network and then dials back to the insecure network 
upon completion of the secure portion of the transaction as described above. 

The geographic tailoring enabled by the WebTV network of the present 
invention offers several other advantages. By knowing where a particular client 
is geographically located using the WebTV network interface device's means for 
determining client location, the server response to client requests can be tailored 
to the client's particular geographic locality. For example, prior art systems 
provide a network capability with which a client may order goods or services 
from a server using an on-line service. These prior art servers, however, respond 
to every client request in the same way regardless of the client's geographic 
location. In the present invention, however, the server tailors its response to a 
particular client by knowing the client's geographical location as determined 
using the apparatus and processes described above. For example, a first particular 
geographical location may have ISDN and cable modem high speed data service. 
Another second particular geographical location may have only ISDN high speed 
data service. If a client A in the first location orders high speed data service from 
a WebTV server, client A is offered a choice between ISDN and cable modem 
service. If client B in the second location orders high speed data service from a 
WebTV server, the client B is only offered the ISDN service. This difference in 
the response to client A versus client B is possible because the WebTV server is 
able to determine the geographical location of the requesting client using the 
techniques described above. Further, once either client A or client B in this 
example selects a desired service, the request for high speed data service can be 
routed to the optimum high speed data service provider for the particular client's 
geographical location. Again, this efficient routing is possible because the 
WebTV server is able to determine the geographical location of the requesting 
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client using the techniques described above. The geographic tailoring enabled by 
the present invention has several advantages. By knowing the geographical 
location of a requesting client, the server can customize an appropriate response 
to die particular client instead of responding in the same manner for all 
requesting clients. Further, the WebTV server of the present invention can 
effectively replace the conventional method of ordering goods and services 
through a voice call and the error-prone information collection methods 
connected therewith. 

The determination and use of client geographical location as provided by 
the present invention is advantageous for other reasons as well. Using the 
techniques described above, the client can obtain its geographical location from 
the private server. This geographical location information can then be passed on 
to other servers with which the client may desire to conduct transactions. These 
other servers or third party servers may be completely independent from the 
WebTV network or WebTV servers. Thus, the WebTV private server can be 
used to optimize the on-line service provided by any independent network 
service provider. For example, a business, such as a florist or pizza parlor, etc., 
could offer an on-line service for ordering goods over a network. For the 
particular type of business, the geographical location may be significant In the 
case of a business requiring delivery of the goods, like the sample pizza parlor or 
florist, the geographical location of the client is needed to facilitate delivery to 
the client In this situation, the private server of the present invention provides 
the geographical locality of the client to the client The client then passes this 
information to the third party server as part of the transaction with the third party 
server. The third party server uses the geographical locality information to 
optimize its transaction with the client without ever knowing that the private 
server of the present invention was involved. 

The present invention is also advantageously used for enabling real time 
game play between networked game players. First, it is important to make a 
distinction here between two types of remote multi-player games, 1) "real-time" 
or "twitch" games, and 2) "non-real-time" games. Twitch games are games that 
require split-second game control by players and cannot tolerate arbitrary 
communication latencies or delays. Twitch games are by far the most popular 
category of video games — typically all Top Ten games are twitch games — and 
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include games such as "Mortal Kombat™, "John Madden Football™," "Sonic 
the Hedgehog™ " and "Super Mario Brothers™." Typically, twitch games 
require less than 100 millisecond communications latency (i.e. delay for a 
player's action to take effect on the screen) for the games to be playable. Twitch 
games usually can not tolerate varying delays in communications latency. 

Non-real-time games are games that are possible to play with substantial 
communications latency and with varying communications latency. Obvious 
games in this genre are "strategy" games such a chess and backgammon, but 
there are also moderate action games such as adventure games like "Return to 
Zork™" by Activision™ or the "King's Quest™" series from Sierra On-line™. 
The AT&T ImagiNation Network™ is an on-line service specializing in such 
non-real-time games. The Internet and the WWW are also used for playing non- 
real-time games. 

One would think that with the popularity of multi-player twitch games, 
on-line services such as the ImagiNation Network™ would offer twitch games 
for their users. However, these services and other services implemented on the 
Internet or WWW do not offer such games; because, it is not possible to achieve 
less than 100 milliseconds (msec) latency, or even consistent latency, given the 
architecture of current public-switched data networks. 

There are substantial (and often unpredictable) latencies through current 
network architectures. Each modem in a communications chain introduces 
latencies as high as 20 or 30 msec (varying by modem manufacturer and model). 
The telephone network introduces latencies (although they are minimal within a 
local calling area). Wide area networks (WANs) introduce unpredictable 
latencies (as much as 1.5 seconds round-trip). In addition, the on-line service's 
computers themselves introduce latencies, typically increasing as the number of 
active users increases. 

As a result, remote multi-player twitch games can only be played through 
a direct telephone connection of one game player to another player, barring a 
major overhaul (requiring enormous capital investment) of the existing public 
access data networks. Consequently, on-line services and Internet or WWW 
based services are limited to hosting non-real-time multi-player games. 
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Although die Internet and WWW arc unsatisfactory networks for real- 
time games due to the latency problems, the Internet and WWW are a good 
source for matching together remote players who wish to play the same game 
together at the same time. This is because the Internet is such a ubiquitous 
network. Thus, it would be advantageous to use the Internet and WWW or other 
public network infrastructure to match remote game players and to post game 
results; yet, use another low-latency network for actually playing the real-time 
game. This problem with real-time networked game playing is not recognized or 
solved by the prior art. The present invention provides the solution as described 
below. 

As described above, the present invention provides a WebTV client 610, 
which initially establishes a secure communication with private server 820 over a 
first network 858 in order to subsequently establish a secure communication 
environment through conventional second network 612. Thus, a first network is 
used to define parameters and enable communications over a second network. 
This concept is used in the real-time game environment as well. However, in the 
real-time game context, the WebTV client 610 initially establishes a connection 
with the WebTV server over a non-real-time network, such as the Internet or 
WWW, in order to request player matching with another remote client wishing to 
play the same game at the same time. Once the server has matched the two 
networked clients as opponents in a networked real-time game, the two matched 
clients disconnect from the non-real-time network and connect with each other 
over a real-time network using network address information obtained from the 
WebTV server. The process is illustrated in more detail in Figure 16. 

Referring now to Figure 16, the real-time network game mechanism of 
the present invention is illustrated. In Figure 16, a flow chart illustrates die 
processing performed by a WebTV client 610 desiring to play a real-time game 
with a networked remote client opponent The logic illustrated in Figure 16 is 
used by a local client 610 to establish a real-time data communication link with 
another remote client 610 over a real-time data network, such as a direct 
telephone link between clients 610. In a first processing step 1610, local client 
610 performs a power-up initialization. Next, local client 610 connects to a 
WebTV server 620 (block 1612) over a non-real-time network line 856 through 
point of presence node 810 or directly on line 852 as shown in Figure 8. Once 
local client 610 is connected with WebTV server 620, local client 610 requests 
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the WebTV server 620 to match the local client 610 with another remote client 
who previously notified WebTV server 620 of the desire to play a specified real- 
time game (block 1614). The local client 610 provides its network address to 
WebTV server 620. The remote client 610 previously provided its network 
address to WebTV server 620. The WebTV server 620 matches the two clients 
using various items of information to effect the match. This information includes 
the geographical location of the clients as indicated by their network address, the 
name or type of real-time twitch game to be played, the skill level specified for 
each client, and other related information. Once the WebTV server matches the 
clients 610, the WebTV server notifies each client of the network address of its 
matched opponent (block 1616). In response, each matched client disconnects 
from the WebTV server (block 1618), and establishes a link on a real-time 
network to the matched opponent In the preferred embodiment, this link can be 
established using a direct telephone line and the network address provided by 
each client is its telephone number. A very low latency communication link can 
be established between matched clients thereby enabling the playing of a real- 
time networked game (block 1620). It will be apparent to one of ordinary skill in 
the art that other conventional real-time network infrastructures may be 
equivalently used to effect the actual game play once the client game players 
have been matched on the non-real-time network. 



MINIMUM COST ON-LINE ACCESS 

Referring now to figure 17, the apparatus to achieve minimum cost online 
access will now be described. The customer/user system 1710 generally includes 
a network connector 1712, processor 1714 and display unit 1716. The network 
connector 1712 via the modem line 1718 is connected to network 1720 that will 
give the customer/user access to the WWW server 1722. Several access 
providers 1721 are configured to achieve access to WWW server 1722 in order 
to give customers and users access to the WWW servers. Generally, the 
customer/user has an account with an access provider which provides the length 
to the WWW server. One embodiment of the present invention provides th 
customer/user with the capability of choosing from a variety of access providers 
in oider to benefit both the customer/user and the access providers. Typically, 
access providers provide a particular service to a particular class of people. For 
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example, one access provider may cater to commercial businesses that generally 
operate during normal business hours where other access providers may cater to 
consumers that generally operate during evenings, weekends, and holidays. A 
system that would allow customers to utilize the access providers during off 
hours would optimize the use of the systems and, therefore, balance out the use 
of a particular access providers system during all hours. From the customers 
point of view, the ability to utilize different access providers during different 
times would greatly reduce the cost of accessing the servers. Thus, the 
customers are able to access various access providers and, in turn, access 
providers are able to make themselves available to a broader range of customers. 

Still referring to Figure 1700, a central accessor 1724 is illustrated in 
accordance with the present invention. The server is connected to the 
customer/user 1710 via modem line 1726 in order to receive an access request 
from a customer/user. The automatic number identification unit 1728 receives 
the incoming call and identifies the customer/user 1710 by the incoming phone 
number as described above. The customer/user will typically have an account 
with the central access server. The central access server 1724 keeps data list 
1730 containing information on internet access provider phone list 1732 and 
customer criteria list 1734. The combination of these two lists provide the 
central access server with enough information to analyze the compatability 
among customer/users and access providers. Customer/user criteria such as time 
of day of the request, day of the week, holidays, occurrence of busy signals 
among access providers, accumulated or projected connect time, quality of 
access, reliability of performance and other criteria are used to find a compatible 
access provider for a given customer. Internet access provider information is 
then compared to the customer/user information in order to find a compatible 
match. An algorithm is then produced in the algorithm generator 1736 and 
delivered to the customer/user 1710 via modem line 1726 to the customer/user 
processor 1714 for use by the customer/user to choose an access provider 1721. 
The processor 1714 then decodes the algorithm and chooses an access provider 
via network 1720. The access provider then provides the customer/user 1710 
access to the WWW server 1722. 

Referring now to Figure 1800, the function of the central access server 
1721 in connection with the network system of Figure 1700 is illustrated. In the 
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first stage 1 840, the customer/user accesses the central access servo- via the 
telephone lines or modem lines 1726 of Figure 17, in order to retrieve 
information pertaining to an access provider. In the next step 1842, the central 
access server receives the access request and indentifies the customer using 
automatic number identification (ANI) as discussed above using conventional 
techniques. In response, in step 1844 the central access server accesses the 
customer criteria list in response to the identification of the customer. In step 
1846, the central access server accesses the internet access provider phone list 
and analyzes the compatability among different access providers and the 
customer/user. Once matches and alternative matches are found, in step 1848, 
the central access server generates an algorithm in the algorithm generator 1736 
and delivers it to the customer/user so that the customer can choose an internet 
access provider according to the customer criteria and corresponding access 
provider compatability. In step 1850, the customer/user receives the algorithm 
and decodes the algorithm so that the processor 1714 can choose an access 
provider in step 1852. Finally, in step 1854, the customer/user connects with an 
internet access provider and accesses the internet 

In a working example, upon initial connection, the client software can 
dial into an 800 number with the central access server. Using ANI the server can 
do a database check on the user's number identified by the ANI and give the 
client software two local phone numbers. First, a local number for one internet 
access provider modem pool caters to business hour access and a second local 
number for another internet access provider's modem pool that caters to non- 
business hour clients. The server can then send an algorithm that is executable 
by the client's software. The client's software would then check the time of day 
and the day of the week, and by using the algorithm, can choose an access 
provider that is compatible. For example, if the time is between 9 a.m. and 5 
p.m. and the day is a weekday, the algorithm may direct the user to dial up an 
internet access provider that caters to business clients. Otherwise, the user may 
be directed to dial up a consumer based system. If it is a holiday, the algorithm 
would act accordingly as well. The algorithm can also allow the user to dial up 
an alternate number in the event that the line to the chosen access provider is 
busy. 
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The algorithm can also be catered to customers that need internet access 
providers that give better rates for heavy or light users. For example, after a user 
accrues a certain amount of connect time in a given month, the central access 
server can direct the user to access a different internet access provider that is less 
expensive for heavy users. Similarly, if a user is typically a very light user, a 
central access server can direct the user to an internet access provider that is less 
expensive for light users. 

In another embodiment, the client software could be catered to check 
with the central access server each time it connects to get new phone numbers 
and a new algorithm by which to select a new access provider. The client could 
then also be directed to dial a different phone number or to log in under a 
different account name. This could be very advantageous in certain situations. 
For example, if an internet access provider provides a certain number of hours 
for a given account, the central access server could direct several clients to share 
several accounts by directing clients when they should log in, under what 
account name and for how long. In this way, the central access server can utilize 
each account up to its maximum amount of time. In the case of accounts with 
flat rate access, such as that off ered by AT&T and WorldNet, a given account 
could be used twenty four hours a day, shared by a number of users, but never 
utilized by more than one user at the same time. 

In another embodiment, upon initial connection to the central access 
server, the central access server determines that the client is in an isolated 
geographical area, the central access server might provide the client with a 
regional internet access provider that has a particularly low rate for that region. 
For example, a nationwide internet access provider may have a low hourly rate 
and an enormous network of modem pools, known as points of presence (POPs) 
throughout the US, but not have a POP in a particular isolated area such as South 
Lake Tahoe, California. There may be a local internet access provider in this 
particular isolated area, however, because of the small economies of scale, the 
local provider may have a higher hourly rate. If the central access server 
determines that the client is in this isolated area, the client could be directed to 
the local internet access provider even though the national internet access 
provider may have a better hourly rate. The central access serv r would then 
determine which access scenario is best for the particular customer. Therefore, 



WO 98/04088 



PCT/US97/12423 



-29- 

the central access server can save money for the user by considering not only the 
cost of the internet access provider service, but also the cost of the phone call to 
reach the alternate internet access provider. 

Thus, an improved apparatus and method for using network address 
information to improve the performance of network transactions has been 
described. 

The specific arrangements and methods described herein are merely 
illustrative of the principles of the present invention. Numerous modifications in 
form and detail may be made by those of ordinary skill in the art without 
departing from the scope of the present invention. Although this invention has 
been shown in relation to a particular embodiment, it should not be considered so 
limited. Rather, the present invention is limited only by the scope of the 
appended claims. 
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CLAIMS. 

We claim: 

1 . A database central routing device for routing incoming access requests 
from at least one user comprising: 

a central server, 

a user identifier for identifying a user requesting access as a customer; 

and 

an algorithm generator configured to generate algorithms pertaining to 
phone numbers of database access providers, wherein the central server is 
configured to download an algorithm according to user criteria. 

2. A database central routing device according to Claim 1 wherein the user 
identifier is an automatic phone number identifier. 

3. A database central routing device according to Claim 1 wherein the user 
identifier is a log-in routine of a modem pool. 

4. A database central routing device according to Claim 1 wherein the central 
server is configured to identify a user and generate algorithms pertaining to die 
user criteria. 

5. A database central routing device according to Claim 1 wherein the criteria 
includes time of day, day of week, holidays, busy signals, accumulated connect 
time, projected connect time, quality of access, reliability, performance of points of 
presence, peak time of providers, off peak time of providers, geographic location 
of providers and geographic location of user. 

6. A database central routing device according to Claim 1 wherein the central 
server includes server software configured to download the phone numbers of 
database access providers based on user criteria. 

7. A database central routing device according to Claim 1 wherein the criteria 
includes location of the user, the availability of database access providers in the 
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user location, the cost of database access providers, the projected usage pattern of 
the user, the projected downtime of the database access providers and the outage 
schedule of the database access providers. 

8. A database central routing device according to Claim 1 wherein die 
algorithm generator generates at least one database access provider account for use 
by the user to log into a database access provider. 

9. A database central routing device according to Claim 1 wherein the 
algorithm generator generates an algorithm to determine which database access 
provider to use and for how long. 

10. A method of routing an access request by a user for communication with an 
internet access provider, the user having a network connector for connecting to a 
modem and a processor for processing information, the method incorporating a 
central access server having an automatic number identification unit, data lists 
having internet access provider phone numbers, customer criteria lists and an 
algorithm generator, the method comprising: 

receiving an access request from the user by the central access server via a 
modem line; 

identifying the user, 

accessing the user's customer criteria in response to the user identity; 
accessing internet access provider phone list; 

determining a compatible internet access provider for the user using the 
user's customer criteria; 

generating an algorithm containing at least one compatible internet access 
provider access number; and 

transmitting the algorithm to the user via the modem line. 
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CLIENT PROCESSING LOGIC 



PERFORM A POWER-UP INITIALIZATION OF CLIENT. 

1110 



THE CLIENT CONNECTS TO A PRIVATE SERVER OVER A SECURE 
NETWORK LINE AND GETS THE NETWORK ADDRESS OF THE CLIENT 
FROM THE PRIVATE SERVER (EG. GET THE CLIENT TELEPHONE 

NUMBER FROM AN ANI SERVER). THE CLIENT GETS AN 
ENCRYPTION KEY FOR THE CLIENT FROM THE PRIVATE SERVER. 

1112 



STORE THE CLIENT NETWORK ADDRESS IN A SECURE CLIENT 
STORAGE AREA. STORE THE CLIENT ENCRYPTION KEY IN A 
SECURE CLIENT STORAGE AREA. 

1114 



I 



GET THE NETWORK ADDRESS OF A LOCAL POINT OF 
PRESENCE NODE FROM THE PRIVATE SERVER. 

1116 
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DISCONNECT FROM THE PRIVATE SERVER. CONNECT 
TO THE IDENTIFIED LOCAL POINT OF PRESENCE NODE. 

1118 



I 



OPEN A CONNECTION WITH THE WEBTV SERVER THROUGH THE 
POINT OF PRESENCE NODE USING THE CLIENT ENCRYPTION KEY 
TO ESTABLISH A SECURE CONNECTION WITH THE WEBTV SERVER 
OVER AN UNSECURE NETWORK LINE. PROVIDE THE CLIENT 
BOX IDENTIFIER AND THE CLIENT NETWORK ADDRESS TO THE 

WEBTV SERVER. 
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LOGIC 
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RECEIVE A REQUEST FROM A CLIENT FOR A NETWORK ADDRESS 

AND AN ENCRYPTION KEY. 



1210 
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USE CONVENTIONAL TECHNIQUES TO OBTAIN THE CLIENT 
NETWORK ADDRESS. FOR A TELEPHONE NETWORK, USE 

CONVENTIONAL ANI TO OBTAIN CLIENT TELEPHONE NUMBER. 
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DETERMINE IF THE CLIENT ALREADY HAS AN ENCRYPTION KEY. 
IF NOT, GENERATE AN ENCRYPTION KEY FOR THE CLIENT. 

1214 



USE THE CLIENT NETWORK ADDRESS TO DETERMINE WHICH 
POINT OF PRESENCE NODE IS LOCAL TO THE CLIENTS 
NETWORK ADDRESS. FOR A TELEPHONE NETWORK, THE PRIVATE 
SERVER FINDS THE TELEPHONE NUMBER OF A POINT OF 
PRESENCE MODEM IN THE LOCAL CALLING AREA OF THE 

CLIENT. 
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RETURN A MESSAGE TO THE CLIENT INDICATING THE CLIENT 
NETWORK ADDRESS, THE CLIENT ENCRYPTION KEY, AND THE 
NETWORK ADDRESS OF A LOCAL POINT OF PRESENCE NODE. 
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WEBTV SERVER PROCESSING 
LOGIC 



RECEIVE A REQUEST FROM A CLIENT FOR AN OPEN CONNECTION. 
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IF THE WEBTV SERVER IS A SEPARATE SERVER FROM THE 
PRIVATE SERVER AND THE CLIENT AUTHENTICATION DATA 
FOR THIS CLIENT HAS NOT YET BEEN INITIALIZED IN THE WEBTV 
SERVER. THE WEBTV SERVER OPENS A SECURE CONNECTION 
WTTH THE PRIVATE SERVER OVER A SECURE NETWORK LINE 
AND OBTAINS THE ENCRYPTION KEY FOR THE CLIENT USING 
THE CLIENT BOX IDENTIFIER AND THE CLIENT NETWORK 
ADDRESS RECEIVED FROM THE CLIENT. THE WEBTV SERVER 
DISCONNECTS FROM THE PRIVATE SERVER. INITIALIZES THE 
CLIENT AUTHENTICATION DATA WITH THE ENCRYPTION KEY 

FOR THIS CLIENT. 
1311 



THE WEBTV SERVER COMPARES THE CLIENT BOX IDENTIFIER 
AND THE CLIENT NETWORK ADDRESS WITH CLIENT 
AUTHENTICATION DATA IN THE WEBTV SERVER. 
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CLIENT PROCESSING LOGIC FOR 
PLAYING REAL-TIME NETWORK GAMES 



PERFORM A POWER-UP INITIALIZATION OF THE LOCAL 

CLIENT. 
1610 



OPEN A CONNECTION BETWEEN THE LOCAL CLIENT AND THE 
WEBTV SERVER THROUGH THE POINT OF PRESENCE NODE 

OVER A NON-REAL-TIME NETWORK LINE. PROVIDE THE LOCAL 
CLIENT BOX IDENTIFIER AND THE LOCAL CLIENT NETWORK 
ADDRESS TO THE WEBTV SERVER. 

1612 



LOCAL CLIENT REQUESTS WEBTV SERVER TO MATCH THE LOCAL 
CLIENT WITH ANOTHER REMOTE GAME PLAYER (REMOTE CLIENT). 
LOCAL CLIENT SPECIFIES GAME TITLE, SKILL LEVEL. AND OTHER 
INFORMATION RELATED TO PLAYER MATCHING. 

1614 



WEBTV SERVER RESPONDS TO THE LOCAL CLIENT REQUEST 
WITH THE NETWORK ADDRESS OF A REMOTE CLIENT WHO 
PREVIOUSLY REQUESTED MATCHING FOR PLAYING THE 
SPECIFIED REAL-TIME GAME. 
1616 
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LOCAL CLIENT DISCONNECTS FROM THE WEBTV SERVER. 
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THE LOCAL CLIENT USES THE NETWORK ADDRESS OF THE MATCHED 

REMOTE CLIENT OBTAINED FROM THE WEBTV SERVER (EG. THE 
REMOTE CLIENT TELEPHONE NUMBER) TO .ESTABLISH A DIRECT 
COMMUNICATION LINK WITH THE REMOTE CLIENT OVER A, REAL- 
TIME NETWORK LINE. REAL-TIME GAME fL/^JNG MAY THEN BE 
INITIATED OVER THE REAL-TIME NETWORK LINE. 

1620 
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